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(57) Abstract: A security ardutecture has been developed tn wtuch a single sig^Hm is provided. Session credeocials are used to 
irpintftin continuity of apersistent session across nmltiple accesses to one or more information resources, and in some emttodiments, 
across credential level changes. Session credentials are secured, e.g., as a oyptographicaUy secured session token, such thai tti^ 
may t»e inspected tyy a wide variety of entities or af^Hcations to verify an authenticated trust level, yet may not be prepared a 
altered except by a ousted auttaecticaticm service. Some onbodiments of the |)a:eseiit invention associate crust levd requirements with 
information re sour ces. Authentication schemes (eg., those t>ased on passwords, certificates, triometric techmques, smart cards, etc.) 
are associated with trust levels, and in some embodiments, with enviiomnentalparai^^ Fbre!C2inp!e;inoneconfigurati6&,alogin 
service (120) obtains login credentials for an entity (e.g., 170) commensurate widi the trust levd requirement(s) of an information 
resource or infonnation resources (e^ 191. 192, 193) to be accessed and with ettviionmem parameters that affea the suffidettc^ 
given credential type. Once login credentials (e.g^ 410) have been obtained for an entity and have been authenticated to a given trust 
level, session credentials (eg.. 420) are issued and access is granted to information resources for which dte crust level is sufficient 
Advant^eously, by using the session credentials access is granted without the need for further login oedentials and autheoticatioa 
In some configurations, session credentials evidencing an insufficient trust level.may be remedied.by a session continuicy preserving 
upgrade of login credentiaL 



600C1D: <WQ_01t1452A?J.> 



wo 01/11452 PCTAJSO0y20931 



ACCESS MANAGEMENT SYSTEM AND METHOD 
EMPLOYING SECURE CREDENTIALS 
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Technical Field 



The invention relates to infonnatian security, and more paiticulariy, to systems and method for 
miproving the security of information transactions over netwoiks. 

Background Ayf 

The internet has become an inqwitant medium for information services and electronic commerce. As 
Ac internet has been commercialized, organizations initially established their presence in cyberspace by 
making-information (typically static, non-sensitive promotional information) available on resources well 
removed from the operational infiastrucmre of Ae organization. Security issues were often addressed by 
isolating publicly accessible resources (e.g., web servers) from more sensitive assets using fnewall techniques. 
As long as the publicly accessible information and resources were relatively non-sensitive and user 
inicractbns with such information and resources was not mission critical, relatively simph firewall techniques 
were adequate. Though information and resources outside the firewall were at risk, the risk conid generally be 
15 limited to non-proprietary information that was easily replaceable if conq>romised. Proprietary information 
and systems critical to day-to-day operations were sheltered behind the firewall and information flows across 
the firewall were filtered to exclude all but the comparatively non-thieatcning services such as electrtmic mail. 

However; as the internet has become more pervasive, and as &e sophistication of tools and techniques 
has mcreased, several aspects of the security environment have changed dramatically. First, businesses have 

20 recognized the power of inforamtion transactions that more tightly cotq>le to operational data systems, such as 
order processing, inventory, payment systems, etc. Such transactions include electronic commerce with direct 
purchasers or consumers (e.g., browsing, selecting and purchasing of books by members of the public from an 
on-hne bookseller) as well as supply chain and/or business partner interactions (e.g., automated just-in-timc 
inventory managcmenl, customcr-^cdfic pricing, availabihty and order status information, etc.). 

25 Commercially relevant transactions increasingly require information flows to and from secure operational 
systems. Second, even infoimati<Mi-only services arc increasingly mission-critical to their providers. 
Corporate image can be adversely affected by unavailability of, or degradation access to, odierwise mm- 
sensitive information such as customer support infomiation, product i^)grades, or marketing and product 
information- Because many businesses rely heavay on such fecihties, both unauthorized modification and 

30 denial of service represent an increasing threat 

Individual information service or transaction system typicaUy exhibit differing security requirements. 
While it is possible to field individualized security sohitions for each information service or transaction 
system, individualized sohitions make it difficuh to maintain a uniform security policy across a set of 
applications OT resources. Furthermore, individuiizcd sohitions tend to foster incornpatibfe 
35 within what would ideally be presented to consumers or business partners as a single, integrated enterprise. 
For example, a user thai has aheady been authenticated for access to an order processing system may 
unnecessarily be re-authenticated when accessing an order status* system. Worse still, a set of individualized 
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solutions is typically only as good as the weakest solution. A weak solution may allow an enterprise to be 
compromised through a low security entry point. 

Another problem with individualized solutions is a veritable explosion in the number of access 
controls confronting a user. As more and more business is conducted using computer systems, users are 
confronted with multiple identifiers and passwords for various systems, resources or levels of access. 
Administrators are faced with the huge problem of issuing, tracking and revoking the identifiers associated 
with their users. As the "user** comnumity grows to include vendors, customers, potential customers, 
consultants and others in addition to employees, a huge "id explosion** faces administrators. Furthermore, as 
individual users are themselves confronted with large numbers of identifiers and passwords, adherence to 
organizational security policies such as password restrictions and requirements (e.g., lengtfi, diaractcr and/or 
case complexity, robustness to dictionary or easily-rascertainable information attack, frequency of update, etc.) 
may be reduced. As users acquire nrare passwords — some individuals may have 50 or more — diey cannot 
help but write down or create easy-to-remember, and easy-to-compromise, passwords. 



C. ^, ^ 20 





DISCLOSURE OF INVENTION 

1 5 Accordingly, a security architecture has been developed in which a single sign-on is provided. 

Session credentials are used to maintain continuity of a persistent session across multiple accesses to one or 
more infonnation resources, and in some embodinients, across credential level changes. Session credentials 
are secured, e.g., as a cryptographically secured session token, such that they may be inspected by a wide 
variety of entities or applications to verify an authenticated trust level, yet may not be prepared or altered 
except by a trusted authentication service. Some embodiments of the present invention associate trust level 
requirements with information resources. Authentication schemes (e.g., those based on passwords, 
certificates, biometric techniques, smart cards, etc.) are associated with trust levels, and in some embodiments, 
widi environmental parameters. For exanq)le, in one configuration, a login service obtains login credentials 
for an entity commensurate with the triist level requirement(5) of an information resource (or information 
^ (jQ 25 resources) to be accessed and with environment parameters that affect the sufficiency of a given credential 
- Vti^^ ^ce login credentials have been obtained for an entity and have been authenticated to a given trust 

level, session credentials are issued and access is granted to information resources for which the trust level is 
sufficient Advantageously, by using the session credentials access is granted without the need for further 
login credentials and authentication. In some configurations, session credentials evidencing an insufficient 
30 trust level may be remedied by a session connnuity preserving upgrade of login credential 

In one embodiment in accordance with the present invention, a sessioii credential includes a principal 
identifier uniquely identifying a principal and an encoding of audiorization accorded by the security 
architecture afler.prior authentication of a login credential corresponding to the princi|>al.. The principal 
identifier and authorization encoding are cryptographically secured and allow the security architecture to 
35 evaluate sufficiency of the authorization for access to the one or more informatidn resources without re- 
authentication of the login credentials. In one variation, the session credential is supplied external to the 
security architecture as a session token. 
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In another embodiment in accordance with the present invention, a session token is provided for 
transfer between a client entity opcratiDg on behalf of a principal and a security architecture controlling access 
to an information resource. The session token includes a principal identifier uniquely identifying the principal 
and an indication of audwrization level accorded by the security architecture after prior authentication of a 
login credential corresponding to the principal. The principal identifier and audiorization level indication arc 
ciyptographically secured and allow die security architecture to evaluate sufficiency of the authorization for 
access to the information resource without re-authentication of Uic login credentials. 

In still another embodiment in accordance wiA the present invention, a method of providing 
audiorization verification in a security architecture controlling access to one or more information resources 
includes obtaining a login credential and audicnticating a principal dxereby and issuing a cryptographically 
secured session credential. The cryptographically secured session credential encodes at least an identifier for 
die princ^l and a first audwiization accorded based on die audienticating. For phxral requests for accesses to 
die one or more of die information resources, die mcdiod further includes selectively allowing access based on 
sufRciency of die first audiorization encoded by die cryptographicaUy secured session credential for access to 
die one or more of die information resources, wherein die selective allowing is performed without additional 
login credential audienticating. 

In still yet anodicr embodiincnt in accordance with the present invention, an information access 
control facility inchides an plication proxy and means responsive to dje application proxy. The application 
proxy is for receiving an access request targeting one of die information resources, extracting a 
cryptographically secured session token from die access request, and selectively proxying die access request. 
The means responsive to ttic application proxy is for evaluaiting sufficiency of an audiorization encoded in die 
cryptographically secured session token for access to die targeted information resource. 

BRIEF DESCRIPTION OF DRAWINGS 

The present invention may be better understood, and its numerous objects, features, and advantages 
made parent to those skilled in die ait by referencing the accompanying drawings. 

FIG. 1 is a block diagram ilhistrating information flows between components in a security 
architecture craptoying secure session credentials in accordance widi an exen^lary enAodnnent of die present 
invention. 

FIG. 2 is a flow chart ilhistrating operation of a security architecture employing secure session 
credentials in accordance with an exemplary embodiment of the present invention, 

FIG. 3' illustrates^ interactions between functional components in a functional decon^xisition of a 
security architccmre employing secure session credentials in accordance widi an exemplary embodiment of die 
present invention. 



.0111462Aa„l_> 



wo 01/11452 



PCT/USOO/20931 



-4- 

FIG. 4 illustrates relations between login credentials, session credentials and a cookie encoding of a 
session token in accordance with an exemplary embodiment of die present invention. 

The use of the same reference symbols in different drawings indicates similar or identical items. 

M OPEf S) roji CA R RYING QUT THE IN Vg^T IQW 

5 Some terminology used in this specification has meaning particular to the context of embodiments 

described herein. Therefore, to aid persons of ordinary skill in the art in understanding the full scope of the 
invention^ some of that terminology is now defined. 

Glossary 

Access Management: Systems, methods and techniques for controllirig use of inftHmation resources. 
10 Typically, access managemerit systems employ both autfaenticaticm and authorization to control access to 
information resources. 

Authentication: A process used to verify, the identity of an entity* As typically implemented, an 
authentication method is employed to verify the identity of a user or object based on a crede n tial sillied by 
the user or object 

1 S Authorization: A process for determining whether an identity is permitted to perform some action, 

such as accessing a resource. Typically, an identity will be authenticated, though in some configurations 
certain identities need not be. 

Credential: Evidence of identity used to authenticate an entity. Exenq>lary credentials types inchide 
passwords, certificates or other encrypted indicia based on asymmetric, symmetric, public, private, or secret 
20 key technologies, one-time passwords, biometric indicia such as by retinal scan, voice print, finger print, etc., 
and possession based indicia such as smart cards. Enigma cards, keys, etc. In some realizations, credentiats 
may be associated with users, sessions, functional objects, etc. 

Digital Signature: A transformation of a message using an asymmetric cryptosystem such that a 
person having the initial message and the signer's public key can accurately determine whether the 
25 transformation was created using the private key that corresponds to the signer's public key and whether the 
message has been altered since the transformation was made. 

Entity: A user or object, including data objects and/or fimctional objects such as applications, 
components, modules, services, processes, threads, etc, as well as instantiations thereof In some 
configurations, only user entities (typically, the human principal interacting with a software program or on 
30 whose behalf a software agent purports to act) are considered. In other configurations, entities include 

functional objects without an associated human principal. The identity of an entity may be authenticated using 
a credential 
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Session: A period and collection of states spanning one or more interactions between an entity and an 
information environment As used herein a session may span nultiple interactions with nuiltiple resources of 
the information environment and, in some configurations, may span multiple infoimadon access protocols 
(e.g.» HTTP, FTP, tehirt, etc.). A session has a beginning and an end. During its existence, a session has state. 
S As used herein, the temn session connotes a greater persistence than as sometimes used to describe the period 
of a "session layer" protocol interaction, which in the case of some protocols, such as HTTP, is generally very 
short-lived. 

Single Sign-on Security Archltectorfe 

FIG. 1 provides an overview of major interactions between components for an exemplary security 
10 ardiitecture in accordance wiA the present invention. As illustrated in FIG, 1, a client application, e.g., a 
browser 170 operated by a user, interacts with the security architecture via a gatekeq>er and entry handler 
component 110 and a login component 120. Gatekeeper and entry handler con^onent 110 provides an entry 
point for external cHent applications requesting access to enterprise applications and/or resources, including 
e.g., information resources 191, 192 . . . 193. for winch access management is provided by the security 
15 architecture. Using facilities provided by a session management component 160, an authorization component 
140, an authentication component 130, an identification component 150, and login component 120» die 
gatekeeper/entiy handler conq>onent 110 allows, redirects or refuses access requests in accordance with a 
security policy. 

Individual information resources typically have differing security requirements. In acidition, 
20 individual types of access to a single information resource may have differing security requirements. 

Nonetheless, a given level of security may be sufficient for more than (me of the information services or access 
types. For exan^le, inforroatimi resource' 191 may include a product hiformation service for providing general 
information such as product descriptions or data sheets to the public, while information resource 192 includes 
an order processii^ system for an eCommerce site. Information resource 193 may include functions for 
25 supply chain interactions such as access to inventory information or cuErent selling price information. Both 
the product information service and order intake functions of the eCommerce may q>crate with similar 
security requirements, e.g.. allowing access by minimally authenticated, non-hostile entities. On the other 
hand, supply chain functions may require a higher level of security. Order status functions of the order 
processing system may require a mid-level of security. 

30 Login component 1 20, operating in conjunction with gatekeeper/entry handler component 110 and 

other components of the security architecture, provides a single sign-on interfecc for access to enterprise 
applications and/or resources. In an exenq>lary embodiment, security requirements are expressed in terms of 
trust levels and login component 120 obtains login credentials for an entity requesting access to one of the 
enterprise applications and/or resources. The login credentials obtained are selected from a set of credential 

35 types that, if authenticated, are sufficient to achieve the trust level requirement of an application or information 
resource to be accessed. Without limitiition, typical login credential types and associated authentication 



430OQ0c <WO_01114fi2A%J_» 



wo 01/11452 



-6- 



PCT/USOO/20931 



mechanisms inchide those based on passwords, cotificates, biometric techniques, smart cards, etc. Other 
credential types and associated authentication mechanisms are described elsewhere herein. 

In some embodiments in accordance with the present invention, gatekeeper/entry handler component 
1 10 queries authorization component 140 to obtain authonzation for access to a particular requested enterprise 
5 application or infomiation resource by the requesting entity (e.g., the browser user). If (he .entity requesting 
access has not yet been authenticated to the trust level required for the particular access to the particular 
enterprise application or tnfoimation resource requested, authorization component 140 may indicate that the 
access request is to be redirected to login conqranent 120 so that togin credentials may be obtained and 
authenticated to a particular trust level. If, on the other hand, login credentials have already been obtained for 

10 the requesting entity and the requesting entity has been authenticated using the obtained credentials such that 
die required trust level has been achieved,.the access will typically be allowed without the need for further 
login credentials and authentication. In certain circumstances, au^rization component 140 may indicate that . 
the access is to be refused. For example, authonzation component 140 may- be programmed to perfomi more 
stringent testing beyond a trust level requirement In an exemplary enterprise tool configuration, a desired 

15 security policy may dictate that a salary tool is accessible only from with a company's internal network. No 
level of authenticated trust may be sufficient to access such a tool from outside coiiq>any network. To 
facilitate implementation of such a security policy, authorization component 140 could refuse access based on 
environment parameters indicating a session originating outside the compan/s mtemal network. 

Of note, in certain embodiments in accordance with the present invention, the mapping of login 
20 credential types and auth»itication mechanisms to trust levels is influenced by environment information such 
as time of request, source of request, connection speed, and/or client application (e.g., browser) environment 
information. In this way, even with a static set ofroapping rules, the set of credential types and authentication 
mechanisms suitable to support a given trust level may vary based on oivironment mfonnatioiL In general, 
mapping nile dependencies are based on perceived variations b threat characteristics and/or requesting entity 
25 capabilities. In some embodiments in accordance with the present invention, gatekeepct/entry handier 
component .110 is the authority on environment information for a particular requesting entity. 

In some embodiments, mappmg rules may be dynamically varied. For example, if a particular login 
credential type and/or authentication method is deemed insecure (e.g., because conq>romised.or because of a 
changing threat profile), the trust level mappings can be updated and have enterprise- wide effect In addition, 

30 several other advantages are achieved by defining the authentication requirement interface between enteiprise 
apphcations and/or resources and the security architecture in temis of required trust levels, rather than in terms 
of particular credential types and audientication methods. First, single sign-on configurations are facilitated 
using an enterprise-wide credential obtaining, authentication and session tracking infrastructure. Second, 
audientication requirements rnay be enforced uniformly in accordance with an enterprise-wide security policy 

35 and with reduced vulnerability to a lax security implementation by any particular information resource. Third, 
credential types and auihemication methods can be added, deleted, or mapped to a new tnist level, all without 
modification of enterprise applications and resources. Of course, all advantages need not be achieved in any 
particular implementation. 
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In ccnaiit embodiments in accordance with the present invention, a credential upgrade facility is 
provided In response to an access request from an entity for which login credentials have ahxady been 
obtained and authenticated, but for which the obtained and authenticated logm credentials are insufiHcient for 
the trust level associated with the requested access, authorization component 140 may indicate that the access 
5 request is to be redirected to login component 120 so that sufficient login credentials may be obtained and 
authenticated to the required trust level Of note, credential upgrade facilities m accordance with certain 
embodiments of the present invention allow upgrade without loss of sessipn continuity. 

ih'aildition to tiie obtained login cfedentialsT some ccmfiguiatioiu in accoriiahcewith the prdint 
invention employ session credentials as a mechanism for evidencing prior audientication of (Stained' login 
10 credentials and for binding individual transactions to a particular session. In some configurations, session 
credentials are also employed in a session token form advantageous for transactions external to the security 
architecture. In an exemplary realiTation, session tokens are encoded for supply to browsers as cookies. 
FIG. 4 illustrates relationships between exemplary login credential, session credential and session token 
objects. 

1 5 As described above, logm credentials (e.g., represented in a form sudi as exemplary bgin credentials 

structure 410) are obtained for a client entity. Typically, login credentials encoded in login credentials 
structure 410 are obtained from a principal via browser client and serve as evidence that the principal (e.g., a 
human user) is entitled to a particular identity. Accordingly, login credentials structure 41 0 encodes a useiid 
and a domainid within which the userld should uxuquely corresporid to a principal. Specific login credmtials, 

20 e.g., a password, a certificate, results of a biomenic process, a response to an Enigma Challenge or results of a 
smart card intenogation, etc are encoded in login credentials stmcture 410, as a tagged value. An 
authenticationScheme is specified and creation time may be encoded to limit replay attacks. In the 
implementation of FIG. 4, login credentials strucnire 410 is encrypted using the public key of an 
authentication service (e:g., of authentication component 130). Because the key is public, any corr^xment, 

25 even untrusted components may encrypt login credentials for provision to authentication component 130, 
while only authentication component can decrypt the encrypted login credentials using its private key. In 
some configuratioBS, secure transfer protocols, e.g., SSL, are en^)loyed to secure login credentials between a 
client entity sucb as browser 170 and the security architectare while encryption with a public key of an 
authentication service is performed within the security architecmre, e.g., at login component 120. In other 

30 configurations, encryption witii a public key of an authentication service may be performed at the client entity. 

If the encrypted login credentials provided to an authentication service are determined to be authentic, 
session credentials are issued In the implementation of FIG. 4, session credentials are embodied in a form 
such as exemplary session credentials structure 420. Encrypted and clear text portions (421 and 422) of 
session credentials structure 420 allow contents of the session credential to be read by anyone and changed by 
35 no one (except die authentication service possessing a private key). Contents of encrypted portion 421 

correspond to diat clear text portion 422 but are encrypted using the private key of die authentication service 
(e.g., of authentication con^wncnt 130). Of note, principal ids. autiiorizations and other contents encoded in 
the session credential may be read by componmts of the security architecmre, and in some embodiments by. 
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components external to the security architecture. Such con^onents can verify the audiecticity of infoimation 
stored in clear text portion 422 using encrypted portion 421 and a public key conesponding to the private key 
of the authentication service. Of note, the information contained in a session credential is generally not 
sensitive. What is sensitive is the state of the information. Therefore, security architectures employing 
5 facitities described herein ensure that information contained in the session credential is provably constant once 
set by an authentication service. By using the public key of the authentication service, which will in general 
be freely available, together with the encrypted information, any application can.read the information (e.g., in 
free text) and ascertain that the session credential was created by die authentication service, and that the session 
credential has not been tanq>cred.with. Assuming that the authentication service's private key has not been 
10 compromised, tampering with the session credential will result in a decryption failure. 

In an alternative implementation (not shown), session credentials may be digitally signed and verified 
by a public key corresponding to a private key. In such an alternative implementatioii, the digital signature 
also allows contents of the session credential to be read by anyone and changed by no one. For some 
configurations, the implementation of FIG. 4 is preferred because encrypted portion 421 can be used as an 
1 5 externally supplied session token. Such a session token representation is a compact representation of the 
session credential particularly appropriate for encoding as a cookie placed at a browser and returned with 
subsequent access requests. 

Referring again to session credentials structure 420, a session id, a principal id, a trust level, group 
ids, a creation time and an expiration time are encoded in both in encrypted portion 421 and clear text portion 

20 422. The session id is a unique identifier for a persistent session maintained by the security architecture. In 
implementations in which credential upgrade is provided or in which a session credential expiration and 
refresh is provided, multiple successively issued session credential instances may encode the same session id 
and correspond to the same persistent session. Principal id encodes an identifier for a princq>al to which the 
security architecture has resolved login credentials. For example, a login credential including a usemamc jdoe 

25 and a password corresponding to jdoe may be resolved by the security architecture to a unique principal id 

associated widi John. Q. Doe of the shipping and rccdving department, having an eropbyee badge number of 
12345, etc. 

In some embodiments, a trust level encodes the audiorization level to which a princqpal has been 
authenticated In such embodiments, the encoded trust level serves as a basis for evahiating ii^ether a 

30 principal associated with the session credentials has been authenticated to a sufficient level for access to a 
requested resource. For example, a trust level of 5 may be sufficient for access to information resources 
having a trust level requirement of 5 or less. Trust levels offer an attractive decoupling of authorization levels 
and authentication methods as described elsewhere herein. However, in soine embodiments, an authorization 
encoding may establish that a principal has been authenticated using a particular authentication mechanism. In 

35 either case, an authorization (e.g., encoded as a trust level) in a cryptographically secured session credential 
allows the security architecture to authorize accesses based on prior authentication of a login credential and 
without involvement of the authentication service. 
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Group ids can be used to grant or limit authorization scope based on group membership. Typically, 
session credentials serve as evidence of prior authentication and authorization for multiple accesses to 
information resources controlled by the security architecture. However, session credentials may be replaced 
on a login credential upgrade as described elsewhere herein. In addition, session credentials of limited 
5 temporal validity may be refreshed by periodic replacement In the configuration of session credentials 

smicture 420, creation time and expiration time allow the security architecture to improve resistance to replay 
attacks. Session credentials typically have a relatively short' expiration time (e.g.. 15 minutes from creation or 
less) and underlying login credentials will be reauthenticated prior to expiration of the session credeatiaL 
Assuming that the underlying login credentials, which are stored under the public key of authentication 

10 coiiq)oaent 130, remain valid, authentication component 130 will issue a replacement cryptographically 
secured session credential (e.g., as session credentiab structure 420). Depending on then current trtist level 
mappings and, in some configurations, depending on then current environment parameters, the authorization 
accorded by the security architectuFC and encoded as a trust level may dififcr from that encoded in the session 
credentia] replaced. If a principal id or bgin credential has been revoked, reauthentication may fail and a user 

1 5 Doay be pronq)tBd to siqiply a sufficient login credentials as described elsewhere hereia Session id and 

principal id will typically remain the same for successive session credentiab associated with a single persistent 
session. 

As previously described, one advantage of the ^roach employed in session credentials structure 420 
is that encrypted portion 421 may also be employed as a compact session token representation 430 of session 
20 credential for use as a cookie. In one embodiment in accordance with FIG. 4, encrypted portion 421 is a string 
encoded representation of approximately 200 characters which may be placed at a browser (e.g.. via transfer 5, 
23 or 23A of FIG. 1) using a set cookie directive. 

Exemplary Configuration 

Referring to FIG. 1, an entity (e.g., a browser 170 operated by a user) interacts wid) enterprise 
25 apphcations and/or resources (e.g., 191, 192, 193) and the security ardiitecture via a gatekeeper/entry handler 
conqx>nent 110 and a login coix9x>nent 120. In general, a wide variety of entities, including human users 
operatir^ browser and/or non*browser cHent applications as well as automated agents and systems, may 
interact with enterprise applications and/or resources and the security architecture as described herein. 
Furthermore, a variety of information resource identification schemes, such as by Uiufoim Resource Locator 
30 (URL), resource address, identifier or namespace designation, may be employed. However, for purposes of 
illustration and not limitation, an exemplary interaction involving a browser and information resources 
identified by URL is described in detail. Nonetiieless, based on die description herein, persons of ordinary 
skill in die art will appreciate a wide variety of conAgurations in accordance with die present invention in 
which non-browser clients, automated agents or other systems interact with enterprise applications and/or 
35 resources and die security architecture using any of a variety of information resource identification schemes. 

Focusing then on an cxen^lary browser-type client entity, browser 170 requests access to one or 
more of enterprise applications and/or resources (e.g., information resource 191) by presenting an URL to 
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gatdcccper/entry handler coniponcnt 110, which acts as a point of entry for client entities requesting access to 
applications and/or resources controUed.by the security architecture, Gatckeeper/entiy handler component 110 
receives the request as a proxy for the requested resource. In some configurations, a combined . 
gatdceeper/entry handler instance is provided, while in others, separate and/or multiple instances are provided 

5 with functionally identical interfaces to other components of the security architecture. In some configurations, 
multiple instances of entry handler functionality (e.g., interception of inbound requests and collection of 
environment, mformation) are provided. For exan^le, cme or more instances for each of several connection 
types (e.g., dialup, WAN, etc.) may be employed. One or more instances of gatekeeper functionality (e.g., 
allowing access for authorized requests and otherwise denying or initiating appropriate responsive action) may 

10 also be provided. Configurations and functional decompositions suitable to a particular enviroimient and 
expected load requirements will be appreciated by persons of ordinary skill in the art 

Entry handler functionality (e.g., in gatekeeper/entry handler component 1 10) ascertains much of die 
requesting clients environment information. For example, for dial-up connections, envirtmment informatioa 
such as line speed and low-level line encryption are ascertained. Additional information, such as source 

1 5 immber (e.g., from caller id information or based on a .callback configuration), signaling type (e.g., POTS or 
digital ISDN), etc., may also be obtained. For network connectioiis, similar environment information (e.g., 
source network and/or node, Virtual Private Network (VPN) low-level encryption, etc.) may be obtained from 
incoming requests themselves or based on a particular entry point (e.g., a particular router or port). More 
generally, gatekeeper/entry handler component 110 obtains and/or maintains information such as connect 

20 location (if ascertainableX ten^ral information such as request time/date, session start time/date, etc. 

(preferably in both die client entity's finme of reference and the security architecture or requested information 
resource's frame of reiference, if location is ascertainable), and client type and/or capabilities (e.g., browser 
type and Java Development Kit (JDK) level). In some configurations, information on line speed, origination 
point (e.g., inside or outside of a corporate network), browser type, encryption capability, number of hops, 

25 latency, system type, etc. may be gathered. Such information is used in some configurations for mapping 

particular authentication mechanisms to tmst levels and for authorization decisions. Environment information 
is generally packaged into a data structure that is associated widi a client sessioa Other components of the 
security architecture may add additional client environment information, such as authentication strength or 
current trust level. 

30 Gatekeeper functionality (e.g., in gatekeeper/entry handler continent 1 10) checks whether a session 

is already associated with the incoming request. Although other techniques are possible, in some 
configurations in accordance with the present invention, gatekeeper/entry handler component 110 checks for 
the presence of a session token in the incoming request. Use of session tokens is described in greater detail 
below; however, in short, a session token may be any data supplied to the client entity for use in uniquely 

35 identifying an associated session. In general, preferred session token implementations are cryptographically 
secured arui include facilities, such as expiration or mapping to a particular connection, to limit risk of replay 
attack and/or spoofing. Some session token iixq)lementations may encode session, principal, and/or trust level 
information. Some session token implementations may employ cookies, URL encodmg, or other similar 
techniques for binding to incoming requests. 
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In some configurations, session tokens are employed to facilitate session continuity and to allow the 
security architecture to associate prior authentication of login credentials with an incoming access request. In 
one utilization, session tokens are issued to client entities as part of an interaction with the security architecture 
and are thereafter presented with access requests. In some configurations, new session tokens (each 
S corresponding to a single session) are issued to cUent entity on each credential level change. In other 

configurations, a session token may remain the same even as credential levels are changed. Session continuity 
means the maintenance of coherent session state across one or more interactions between an entity and an 
information environment 

Components of session state (e.g., in some configurations, principal i4 session id, authenticated trust 
level, group ids and/or roles, creation time, e)cpiration time, etc.) are maintained or advanced throughout Ihe 
duration of a session. Typically, aspects of session state are represented internally by the security architecture 
and a session token (e.g., a session id encoded in a cryptogiaphically secured session token) allows the security 
architecture to reference into die internal representatioa However, in some configurations, at least some 
aspects of session state may be represented or duplicated in the session token. For exanq>le, a principal id and 
current trust level are encoded in one realization of a ciyptogiaphically secured session credential and 
aissociated session token or cookie. In general, a variety of facilities, such as cookies, can be used to maintain 
state across a scries of protocol interactions, such as HTTP transactions, that do not otiicrwise support 
persistent session state. 

Refeiring again to FIG. 1, if a session token is present in the incoming request, gatekeeper/entry 
handler component 110 resolves the token to a session object Alternatively, if no session token is present or if 
a session token is invalid, gatekeeper/enny handler component 110 establishes a new session (2). In an 
exetnplary configuration in accordance with FIG. 1, session management component 160 allocates a new 
session and supplies associated default session credentials (2) based on the requested information resource and 
environment information. Note that a session is created irrespective of authentication status or identity, 
although some implementations may refuse to even allocate a session based oa particular information resource 
requests and/or environment information. Given a session object, which may be resolved from a received 
session token or newly allocated, gatekeepeWentry handler ccmapaDsaX 110 interacts (3, 4) widi authorization 
component 140 to determine whether die requested access is audiorized. For some requested accesses and 
security policies (e.g., 8n<mymous ftp access to certain archives), even a session without authenticated login 
credentials (trust levels) may be audiorized For others, a more substantial trust level' may be required 

Gatekeeper/entry handler coix^Kment 110 supplies authorization conqKment 140 widi an identifier for 
the requested resource (e.g., die requested URL) and an identifier for die associated session. Preferably, die 
associated session identifier is cryptographically secured (e.g., as a signed session credential). In some 
configurations, the signed session credential is obtained &om the conesponding session object In the case of 
35 a pre-existing session, the signed session credential may be obtained using a received session token. In any 
case, authorization component 140 receives (3) the requested resource and session identifiers and responds (4) 
in accordance widi the trust level requirement of the requested resource. In configurations for which 
sensitivity to a changing environment is desired, environment information may also be supplied to 
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authorizatioD component 140. In an exemplary configuration, authorization component 140 responds witti an 
ALLOW, REDIRECT, or REFUSE response based on the sufficiency of a current tnist level. In some 
configurations, authorization component 140 dynamically calculates a current trust level based on.the signed 
session credentiais and environment infom:)ation. In others, authorization component 140 may base its 
5 ALLOW, REDIRECT, or REFUSE response on a ^'current" tmst level previously associated with the signed 
session credentials. Generally, an access request with sufficient current trust level is ALLOWED and 
forwarded (14) without further authentication. An authorization request without proper parameters (e.g., 
without a specified information resource or without a properly secured session credential) .may be REFUSED. 
Authorization requests associated with a client entity that has been blacklisted or for a resource for which the 

10 associated client entity cannot be authenticated using any available method to achieve die required trust level 
may also be REFUSED. For exan^le, a given security policy and associated trust level mappings may dictate 
a REFUSE response in response to an access request to a sensitive resource (such as Hhancial data) by any 
client entity (even a browser supplying the digital certificate for the CFO. and therefore presumably operating 
on behalf of the CEO) if the access request is received over a dial-up line and originates from an unknown 

1 5 munber or is received outside of working hours. 

In general, there is an tnqplictt, base level of enviromnent inherent in an authenticated trust level; 
however, in some configurations, a particular audiorization transaction may dig deeper into.environment 
mfonmation before responding. For exan^le, in configurations providing log-up capabilities, an ..authorization 
service will typically redirect to a login service if the trust level associated with current.session credentials^is 
20 insufficient for a requested access. However, for sensitive applications in such a configuration, an^inadequate 
tmst level may result in a REFUSED message rather than a log-up REDIRECT depending on the particular 
security policy irr^lemented. 

A REDIRECT rcs[>onse is used to forward the access request to login oon^xment 120 so that 
suf&dent login credentials may be obtained and authenticated to achieve the required trust level for the 

25 requested access. Note that in some configurations, both initial login crederitialing and credential, i^grade are 
provided using the REDIRECT facility. In response to a REDIRECT response (4), gatekeeper/entry handler 
component 110 redirects (5) browser 170 to login coirqwncnt 120. In one configuration, gatekeeper/entry 
handler component 110 issues a client-side redirect via HTTP location directive to forward the request to login 
component 120. Parameters such as required trust level, requested URL and^oedential passing method can be 

30 encoded in the redirect URL and suf^Hed (6) by browser 170 to login component 1 20. Altmiatiyely^ some 
parameters can be passed (5A) directly (e.g., through a HttpSession object).although a stateless configuration 
is preferred 

A session token is passed to browser 170 in conjunction with the redirect (5) tO; login component 120. 
Based on the description herein, persons of ordinary skill in the art will appreciate a number of suitable 
35 mechanisms for passing the session token, including diose based on cookies and URL encodirig. Preferably,, 
mechanisms employed are based on focilities provided by commercially available browsers (e.g., in 
accordance with HTML 3 jc, 4.x or other de-facto standards), although customized or plug-in facilities for 
receiving and supplying session token may be en^loyed. In one suitable configuration, the session token is 
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ciyptDgraphically secured and enaxicd in a cookie placed at browser 170 using a set cookie directive 
embedded in the redirect. Odier configurations nay use a less persistent session identification method, such as 
passing an identifier or session token in the redirect URL without storage at browser 1 70. Still other 
configurations may tranahit a session token, a . session credential, or identifier such as a session handle for 
5 storage in a medium such as a smart card. In configurations providing credential upgrade, penistent session 
identification methods are generally preferred, even for a not yet authenticated client entity, for consistency of 
approach. Note that although the identity of the client entity may not be authenticated to a sufficient level of 
trust, the redirected request includes a session token that at least identifies the session. Other configurations 
may omit the bmding of session tokens to sessions of not yet authenticated client entities, though with some 
10 increase in complexity of login component 120. 

Browser 170 sends (6) login component 120 a new access request using the URL specified in the 
redirect from gatekeeper/entry handler component 110. In configurations cn^loying cookies as a medium for 
passing session tokens, the new access request will include the cookie and dierefore die session token. Note 
that in configurations in which the security architecture controls access to resources in several domains, care 

1 5 should be exercised to select a tag or tags for the cookie such that it wOl be provided through noraial operation 
of the browser in subsequent accesses to any of the several domains. Persons of oniinary skfll in the art will 
appreciate suitable tagging techniques, including die use of mult^>le cookies. Login component 120 receives 
die access request and detemoines an appropriate authentication scheme based on mapping rules that identify 
those authentication schemes which are sufficient to achieve a given tmst le\'el. Preferably, die mapping rules 

20 are a function of environment information. In some configurations, mapping rules are implemented as fuzzy 
sets wherein acceptable authentication schemes are a ftmction of required trust level and environment 
information. In tiiis way, environment affects the set of authentication schemes sufficient to meet a trust level 
requirement 

Generally, mapping rale logic is typically evaluated before a user is challenged to auAenticate. 

25 Mapping occurs as a function of session environment arid particulars of die information resource for which 
access is requested. By evaluating the minimum trust level required by the target of an access request, a 
service (e.g., a bgin service such as provided by login component 120) derives a list of potential 
authentication methods. The service dien checks current session environment against the allowed environment 
states for each potential authentication method to trim the list further. If there is no particular resource for 

30 which access is being requested (e.g., if a user jun^ straight to a sign-on page without requesting an accessX 
die service will proceed- according to die lowest level of trust available consistent with session environment 
Otiicr configuraticms may employ differing default behaviors. 

In some configurations, login conqwnent 120 queries (7) authorization component 140 to identify the 
set of authentication schemes diat meet or exceed the required trust level given a current enviroimienL In 
35 other configuraitions, the mapping is performed by login component 120. In either case, login con^nent 120 
supplies (9) information to browser 1 70 to allow die user to select from the suitable authentication schemes 
and to provide an associated login credential. In some configurations, login component 120 supplies browser 
170 with a login page (e.g., HTML) that prompts die user for an application specific user ID and a choice of 
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autbenticatioD schemes. Interactions with browser 170 depend on'the set of credential types that, if 
authenticated, would be aifTictent to meet the trust level requirement for access to the requested resource. For 
example, if more than one type of credential would be sufiBcient, login component 120 may interactively allow 
a user to select from amongst the credential types (e.g., using any HTMl^bascd dialog). Once a particular 
5 credential type has been selected, login component 120 mtcracts with browser 1 70 to obtain an instance of the 
login credential to establish the identity of the browser user. 

Some credential types (e.g., usemame/password pairs, onetime passwords, enigma challenge, etc) 
may be obtained through* an interactive process in which the user supplies die login credential(s) entry into an 
HTML form browser 170 POSTs form contents back to login component 120. Others (e.g., digital certificates) 

10 may be supplied (10) for the client entity from browser 170, or in some configurations, nay be obtained from 
or via an agent or certificate authority. A personal digital certificate (such as those issued by Verisign^, 
Thwate, Entrust or other certificate authority) may be obtained from a browser 170 using an HTTP certificate 
request. Although credentials may be transacted in a variety of ways, credentials are typically obtained from a 
user. Typically, the obtaining is indirect by asking the user's browser to con^lete the negotiation process. In 

15 such configurations, certificate-based authentication may be transparent to the user. In some configurations, 
fur^er authentication can be performed by using information encoded within the certificate to query a 
certificate authority for current status or a lookup to an authentication database may be. performed for more 
detailed requirements. In an exeitq;>lary configuration, the more detailed information could relate to session 
environment or could force an additional name/password authratication as part of the certificate authentication 

20 chain. In a particular iirq>lementation such facilities can be provided by maj^ing rule encodings that require 
successful authentication using multiple authentication methods to achieve a given trust level. 

Once login credentials have been obtained by login corrq>onent 120, they are siq>plied (1 1) to 
gatekeeper/entry handler component 1 10 for authentication. In configurations in v/iach both gatekeeper/entry 
handler component 110 and login con^nent 120 have access to a shared object such as the HttpSessioo 
25 object, login credential passing via the shared object is suitable. In other configurations, an HTTP POST may 
be employed In an exen^lary configuration, the particular credential passing method is selected as part of the 
original HTTP redirect (e.g., encoded in the redirect URL) although other configurations need not allow for a 
selection or may employ other facilities for selection of a credential passing method 

Login component 120 also passes control of the access request back to gatekeeper/entry haiKiler 
30 conqxment 110. In an exemplary configuration, login component 120 issues a new HTTP request (11) 
specifying the originally requested URL, which has been stored in the HttpSession object. As before, 
gatekeeper/entry. handler component 110 receives the request. Gatekeeper/entry handler component 110 
extracts the bgin credentials from the request or fixun the HttpSession object and passes (12) the login 
credentials to authentication component 130 for autbenticatioa Audientication component 130 authetuicates 
35 the login credential, and if successful, queries (13) identification con^nent 150 to establish a correspondence 
wid) a set of entity descriptors that uniquely identifies the requesting entity. In an exenq3lary configuration, 
entity descriptor types include: entity id, system id (e.g., name^assword), certificate, enigma id, smartcard 
token, name/address, and phone. One or more of values may uniquely identify an entity and one or more 
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entity dcscripior types may support multiple values (e.g., multiple digital certificates, namc^sword pain, or 
phone numbeis per identity). Once Ae requesting entity has been identified (14), session parameters are 
updated (15) and session management conqwnent 160 supplies (16) session credentials. Preferably, session 
credentials are digitally-signed or otherwise cryptographicaily secured and returned (1 7) to gatekeeper/entry 
S handler component 110. 

Gatekeeper/entry handler component 110 again siqjplies (18) authorization component 140 with an 
identifier fpr the requested resource (e.g., tiic requested URL) and an identifier for the associated session (e.g., 
the signed session credentials, au&orizatiori consent 140 iesi» 

REFUSE response based on die sufficiency the session credentials (and undedying authentication of login 
1 0 credentials) for die trust level required for Ac requested access. Login credentials should now be sufficient for 
access to die requested resource and an ALLOW response is supplied (19) by autiiorization component 140. 
Gatekeqf)er/entry handler conqwnent 110 proxies the requested access (20, 21) to information resource 191 
and streams (22) results back to login con^ncnt 120. Login consent 120, in turn, streams (23) results 
back to browser 170. 

15 In some embodiments in accordance with the present invention, session continuity is facilitated by 

supplying a session token to browser 170. For example in one configuration, login component 120 supplies a 
session token using a set cookie directive encoded with die results streamed (23) back to browser 1 70. In 
response, browser 170 stores the cookie using a tag (typically a filename encoding). Browser 170 supplies the 
cookie (and the session token) with subsequent access requests based on a correspondence between the tag and 

20 die requested resource. Typically, the conrespondence is based on the sccond-levcl domain (e.g., suacom) in 
which the requested resource is hosted, altfiough nth-level domains or other resource identification and session 
taken associating schemes may be employed. In configurations in which flic security architecture controls 
access to multiple domains across >Wuch a spanning single sign-on is desired, multiple cookies may be 
employed. 

25 Although the encoding of session tokens using cookies is presently preferred, in part because cookie 

facilities are widely suj^ited and reasonably well accepted, other fecilities may be en^loyed to establish 
session continuity. For example, alternative URL encodings and/or custom or phig-in support for session 
identifier receipt, storage and supply may be employed. Also, some configurations may enqdoy lower-level 
session identifiers, e.g., as provided by a particular connection type such as trusted caller id information or as 

30 associated widi a low-level Ime encryption or virtual private network infrastructure. As such facilities are 
likely to be connection-type specific, it is envisioned ttiat they may be used in conjunction with other session 
identifier facilities described above, e.g., session tokens encoded in cookies. In one configuration, the unique 
Etiiemet MAC address associated with a network interface card may be employed as a session handle. TTie 
MAC address is tiicn used to associate with a particular set of session credentials maintained by a central 

35 authority. In general the representation of a session handle can take may fomis. 

Referring again to FTC 1, subsequent access requests (e.g., access request 1 A) include a previously 
assigned session token. As described above, gatekeeper/entry handler con^nent 1 10 uses the session token. 
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if provided to resolve a session object containing session credentials, and to determine whether previously 
authenticated credentials are sufficient for the requested access. As described above, authorization component 
140 niay be queried using session credentials and an identifier for the requested resource to determine 
sufficiency of previously authenticated credentials. In some configurations, sufficiency is determined using 

5 trust level mappings as described above. Depending on the information resource to which access is requested, 
and in some configurations depending on current session enviromnent information, access request 1 A may or 
may not have associated previously authenticated credentials sufficient to support the requested access. In the 
case of an access request 1 A having a trost level requirement commensurate with previously obtained and 
authenticated credentials (i.e., an access request for which no additional credentials need be obtained via. login 

to component 120). die access request is proxied (20) and results (21) are streamed dirccdy (23A) back to 

browser 170. In some configuraticms, gatckeeper/entiy handler component 110 supplies an updated session 
token using a set cookie directive encoded with the results streamed (23 A) back to browser 170. An updated 
session token, if supplied, resolves to the same session object as the session token replaced. For example, in 
some configurations, both session tokens encode a same session handle, although other aspects associated with 

1 5 session token security such as expiration may be updated, in other configurations, results (21 ) are streamed 
(23A) back to browser 170 without an updated session token. In such configurations, the previously supplied 
session token remains valid until expired or otherwise invalidated. Some variations onay enq>loy a session 
token re&esh interval. 

Depending on the information resource to which access is requested, previously obtained and 
20 authenticated login credentials may be insufQcient for the tnist level requirement associated with requested 
access lA. As before, authorization component 140 supplies gatekeeper/entry handler component 110 widi an 
ALLOW, REDIRECT or REFUSE response based on the trust level accorded based on the previously 
obtained and audienticated login credentials and on the trust level requirement associated. with requested 
access 1 A. Advantageously, authorization of individual access requests is streamlined by the encoding of tmst 
25 level in a cryptographically secured session credential or token. In the. case of insufficient credentials, a 

REDIRECT response is supplied and gatekeeper/entry handler component 110 again redirects (5) browser 1 70 
to login componem 120. Additional login credentials are obtained as described above with reference to initial 
credentials. Upon successful authentication, access request is proxied (20) and results (21) are streamed (23A) 
back to browser 170. 

30 Preferably, gatekeeper/entry handler coxzqxment 110. supplies an updated session token using.a set 

. cookie directive encoded with the results streamed (23A) back to browser 170. An updated session tdcen, if 
supplied, resolves to die same session object as the session token replaced. As a result, session state (including 
e.g., identity mappings, authorizations, roles, pcmiissions, environmental variables, etc.) is fnainminrd through 
the credential level change. However, in the case of a credential upgrade, the session object now encodes a 

35 login credential successfully authenticated to achieve a higher trust level. In one advantageous configuration, 
the achieved (higher) trust.level is encoded in a cryptographically secured session token representation as a 
cookie streamed (23A) back to browser 170 with results (21). 
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FIG. 2 illustrates operation of an exemplary security architecture providing a single sign-on fecility 
wi& trust level mapping to auihcnticaiion requirements. As before, an access request is received (201) horn a 
client entity. If the request docs not contain a session identifier (eg., a session key or token) or if the request 
can otherwise be reliably associated with a session maintained by the security architecture, a new session is 
5 created (202). A trust level requirement is determined for access to the requested resource in the context of the 
requesting session environment In some configurations^ as described above, the determination is performed 
by an authorization service such as authorization component 140. Given a trust level requirement, current 
session crc<^tials are evaluated (203) in the context of sessioii rayirqnii^rmfQniiatipn to determine, v^ether , 
die previously supplied bgin credentials are sufficient to achieve the required trust level. In one advantageous 
1 0 realization of session credentials and tokens, a cryptojgraphically secured encoding of trust level allows 

authorization to be confinmed' without involvement of an authentication service (e.g., with reauthentication of 
login credentials). In the case of a newly created (202) session* the authorization evidenced by session 
credentials will typically be insufficient, aldiough some security policies may allow anonymous access to 
certaiii resources. 

1 ^ For a pre-existing session, i.e*, for an access request that can be reliably associated with a persistent 

session by a cryptpgraphically secured session token or otherwise, session credcntiab may or may not be 
sufficient for access to the currently requested resource. For example, affer a first access, die identity of an 
entity accessing resources controlled by the security architecmre will be authenticated to a trust level sufficient 
for diat access. Depending on the trust level requirements of a subsequent access and, in some confijgurations, 

20 depending on then current trust level mailing rules and environment information, the level of trust associated 
with a current session (e,g., as evidenced by current session credentials) may or may not be sufficient for the 
subsequent access. In situations for ^ch a current level of trust (e.g., resulting from prior authentication of 
login credentials for an entity associated with the session) is sufficient for later access to the same or to another 
information resource, access is allowed without additional authentication. For exan^le, in some security 

25 architecmres in accordance widx the present invention, die security architecture proxies (204) the request to the 
requested information resource and streams (205) a resulting response back to the requesting client entity. 

As described elsewhere herein, sufficiency of current session credentials is determined using mapping 
rules diat, in some realtzations» include environment information. In general, current session credentials may 
be insufficient (1) because die identity of the requesting client has not yet been audienticated (e.g., in a first 
30 access situation), (2) because of a higher trust level requirement for the requested access, or (3) because of a 
change in m^ing rules or environment diat causes a previously sufBcient credential no longer be sufficient 
for a particular trust leveL Whatever the reason for the insufficiency, a request corresponding to a session and 
client entity that IS insufficiently authenticated, and that is therefore not authorized, is passed to a facility for 
obtaining credentials of a type that, if authenticated, will support the required trust level. 

35 Typically, session credentials and/or an associated session token encode an e3q)iration time (see 

description, above, of FIG. 4). In such configurations, a previously sufficient session credential is insufficient 
after its expiration. In some configurations, session credentials are periodically refi-eshed by reauthentication 
of die underlying login credentials. For example, in one implementation; a presented session token indicating 
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expiration in less than five (5) minutes causes the security architecture to reauthenticate (not shown) 
underlying login credentials stored in a corresponding SessionObject (e.g., under the private key of 
authentication component 130). Reauthentication typically results in a new session credential and associated 
trust level. Depending on then instant mapping rules, the associated trust level may or may not be suflktent 
5 Also, reauthentication may fail if the login credentials have been.invalidated, revoked or if the login 

credentials have expired. Assuming that reauthentication of login credentials is successful, updated session 
credentials are issued, for exan^le, by authentication component 130 and supplied (e.g., as a cookie encoded 
session token) to the client entity e.g., browser 170). 

Referring again to FIG. 2, a request corresponding to a session not authorized for a requested access 

10 is redirected (206) to a credential gathering service (e.g., login component 120). The credential gathering 
service receives (207) .the redirected access and obtains (208) a trust level requirement for the requested 
access. In some configurations, the trust level requirement may be passed with, the redirected access or 
otherwise associated with the redirected access, in others the trust level requirement may be re-obtained from 
an authorization service such as authorization component 140. A nust level requirement is mapped (209) to at 

15 least one authentication scheme sufficient to achieve the requirement based on current trxtst level mappings 
and, if employed in the,m^ping rules, based on current enviromnent information. Assuming lhat at least one 
autiientication scheme is available diat, if successful, will support the required trust level, login credentials of 
that type are obtained (210) for the entity and authenticated (211). Some credential types (e.g., 
nseroazne/password pairs, onetime passwords, eaigma challenge, etc) may be obtained^through an interactive 

20 process in which a principal (e.g., a human user) supplies thc.credential(s) entry.in an HTML form and POSTs 
form contents back to the credential gathering service. Others:(e.g., certificates) may b&obtained for the client 
entity from an agent or authority. For exao^le, a personal.digital certificate (such as those issued by 
Verisign™, Thwate. Entrust or other certificate audiority) may be obtained from a browser using an HTTP 
certificate request In some configurations, a choice of credentia] types may be provided and user may select 

25 from a set of credential types suRicient for the requested access. Once spptoprnxc login credentials have been 
obtained and authenticated, die session corre^nding to the requested access is updated (213) to reflect the 
new authenticated session credentials. The now sufficiently authorized request is proxied (204) and results are 
streamed back (205) to the requesting client entity. Updated or refreshed session credentials are typically 
supplied as a session token (e.g., a cookie) encoded with the strean^d results. 

20 FIG. 3 iUustrateS:interactions between functional components in an exen^lary functional 

decomposition of a sectirity architecmre. An on-line order processing transaction is exenq>lary and functional 
boundaries are merely illustrative. Based on the description herein, a wide variety of suitablc.cntcrprise 
information environments and functional decon^ositions in accordance with die appended claims will be 
appreciated by persons of ordinary skill in die art. 

35 In the configuration of FIG. 3, application and central security portions (321 ,and 322, respectively) of 

the security architecture are illustrated. Of rxote, functional components of application security portion 321 arc 
typically hosed as services on a first server environment, functional conq)Qnents of central security 
portion 322 are hosted as services on a second server environment In this way, most interactions amongst 
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functional components occur within a single server environment and do not require nctwoik transactions. In 
die configuration of FIG. 3, oedentials associated with a calling component (e.g., framework credentials 
associated with application security framework 303 or application credentials associated with order 
management service 312) are used to establish sufficient authorization for network transactions. Other 
5 configurations may be en^loyed, however, the relatively small number of network transactions (e.g., 

authentication transaction 331 and optional value passing transaction 332) tends to improve performance of the 
security architecture. Of note, authentication transaction 331 need only be performed on login credential 
authentication (e.g., at initial sign-on or credential upgrade) or reauthenticated (e.g., to refresh session 
credentials). Vahie passing transaction 332 provides an optional facility for passing values amongst multiple 
1 0 components of a distnbuted application (c.g.» a distributed implementation of order management service 31 2) 
wherein application credentials are used to mediate storage and retrieval of vahies in a central registry. 

User 301 interacts with browser 302 to place an ozder with order management service 312. An 
application security framework 303 receives an access request including the order and, operating in 
conjunction with a variety of other services, provides a single sign-on facOity substantially as described above. 

15 If the order does not include a session token or cannot be odierwise associated with corresponding valid 
session credentials, dien session credentials are obtained. As ilhistrated in FIG. 3, session credentials are 
obtained using login credentials {e.g., a usemamce/password pair, a digital certificate, etc.) Typically, an access 
request widiout session credentials wiU not have associated login credentiab. As a result, and default Ibgm 
credentiab (e.g., tdentity^anonymous) arc used during initial phases of a single sign-on process. Nonetheless, 

20 in some configurations, login credentials may be- provided with an initial access request More typically, an 
initiat access request is received by application security framework 303 without session credentials or without 
prior presentation and audientication of login credentials sufficient to access the requested resource. In 
response to credentiargathcring operations, a subsequent request is made with login credentials that purport to 
be sufficient, if authenticated, to meet the trust level required for access to order management service 312. In 

25 such a case, session credentials are obtained by passing login credentials to a central security framework 304. 

Authorization of application security framework 303 for access to conqx>nents of the central security 
portion 322 is checked by query to central authorization service 306. Assuming fliat framework credentials 
evidence siifEcient au^orization, login credentials are authenticated by central authentication service 307. 
Central authentication service 307, in turn, interacts with central principal registry 310 to establish the identity 
30 and groi^) membership of user 301 and with central session registry 311 to create a persistent session for 
subsequent accesses by user 301. Particulars of Ae request arc logged to central audit service 308 and, if 
audientication was successful, session credentials are returned to application security framework 303. 

Signed session credentials are presented to application authorization service 313 together with an 
identifier for the requested resource and optionally with an identifier for a particular function or facility of the 
35 requested resource. In response, application authorizatidn service 313 checks the authorization of the principal 
(e.g., of user 301) associated wifli the session credentials to access the requested resource. Application 
authorization service 313 interacts with application resource registry 314 to identify trust level requirements 
for the requesied resource (and in some configurations, for a particular function or facility of the requested 
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resource) and detennines the sufficiency of a current trust level evidenced by the session dedential. Note that 
trust level is assessed by inspection of the session credential and without interaction with an authentication 
service. In some configurations (e.g., as illustrated in FIG. 3), group membership is also evaluated as part of 
the authorization check. 

5 If the signed session credentials indicate that the requesting entity, e.g., browser 302 on behalf of user 

301, is suHiciently authorized to access order managemeot service 312, a CreateOrder request is passed to 
order management service 312 and order processing proceeds in accordance with normal handling diereof. 
Additional accesses may be required, e.g., to select delivery options or to confirm some aspect of die order. 
Assuming that the additional accesses do not require a higher trust level, they will be passed to order 
1 0 nmnagement service 312 based on the correspondence of session credentials with trust level requirements. 

If an exception is thrown due to insufficient authorization, e.g., if the signed session credentials, do 
not indicate diat the requesting entity is sufficiently authorized to access order management service 312, a 
login credential gathering process is initiated. Based on the required trust level and on rules that encode the 
sufficiency of authentication schemes, a login credential is obtained from user 301 and/or browser 302. The 

1 5 obtained login credential is of a type that, if authenticated, is sufficient to meet the trust level requirement for 
access to order management service 312. Aspects of an exenq>lary credential gathering process are described 
in greater detail above. However, as an exanq}le, FIG. 3 ilhistrates the obtaining of a usemame/password pair. 
Once login credentials are obtained, they are passed to central security framework 304 (as described above) for 
authentication by central authentication service 307 so that session credentials can be obtained, the requested 

20 access can be audiorized, and the order processing initiated. Signed session credentials, typicaUy embodied as 
a cryptographically secured session token.that may be stored as. a cookie, are passed back to browser 302 with 
results of the requested access. In this way, subsequent access requests are identified as part of a session and 
authorization may be quickly confirmed without unnecessary re-authenticatioa 

Exemplary Implcmgntfltions 

25 In an exemplary embodiment, at least some of the above-described comp<Hients are implemented as 

servlets executable in the context of a commercially-available web server environment For example, the 
Java™ Embedded Server (JES) architecture with extensions for certificate handling, HypeiText Transfer 
Protocol (HTTP), Simple Network Management Protocol (SNMP), Secure Sockets Layer (SSL), extensible 
Markup Language (XML) grammar processing and security Access Control List (ACL) support available from 

30 Sun Microsystems, Inc. is one suitable environment Java and all Java-based marks and logos are trademarks 
or registered trademarks of Sun Microsystems, Inc. in die United States and other countries. 

In general, the description herein is focused on aspects of a security architecture, radier than cm 
peculiarities of a particular implementation environment It is envisioned that security architectures in 
accordance widi the teachings of the present invention may be irr^lemented in the context of many 
35 conunercially-available networked information service environments, including web server environments, as 
well as in custom environments and enviroiunents that in the future will be developed. However, to facilitate 
an understanding of broad concepts using a specific exemplary enviroiunent, and without limitation, the 
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description herein may include icnriinology specific to the Java Embedded Server (JES) architecmre. 
Nonetfaeless. based on this description, persons of ordinary skill in the art will appreciate implementations 
suitable for other environments. The scope of the invention, as defined by the claims that follow, is not limited 
to any specific in^lementation environment 

5 While the invention has been described with reference to various embodiments, it will be understood 

that these embodiments are illustrative and that the scope of the invention is not limited to them. Many 
variations, modifications, additions, and improvements are possible. For example, the set of authentication 
schemes described herein is illustrative and embodiments in accordance with the present invention may 
include others, including those that may be hereafter developed. If employed, rules mapping trust levels to 

1 0 authentication schemes may be encoded in a variety of ways depending on the particular implementation. In 
general, such m^ing rules may be encoded as static or dynamic table associating trust level to authentication 
schemes. Alternatively, niuapping rules may be encoded as predicates or in other declarative fori^ Mapping 
mles may be encoded in a weighted logic or fuzzy set form. Additionally, particular mappings may depend 
environment infonnation. FurAcrmore, evaluation of mapping rules may be performed in a variety of 

1 5 functional components such as an authorization service, a credential gathering service or a gatekeeper. 
Session continuiiy may be provided using cryptographically secure session tokens passed as cookies or by 
other nxechanisms. 

In some configurations, a session token is a compact eztcrypted representation of at least selected 
contents of a session credential Other compact representations corresponding to a session credentia] niay be 
20 employed. Alternatively, the same representation of session credentials may be employed both within the 

security architecture and outside die security architecmre (e.g., at a browser or other client). Suitable contents 
of a session credential (and session token, if employed) will be appreciated by persons of ordinary skill in the 
art based on the description herein of specific examples. 

More generally, plural instances may be provided for components described hercfin as a single 
25 instance. Finally, boimdaries between various components, services, scrvlcts, registries and frameworks are 
somewhat arbitrary, and particular operations arc ilhistratcd in the context of specific illustrative 
configurations. Other allocations of functionality are envisioned and may fall widiin the scope of claims that 
follow. Structures and functionality presented as discrete components in the exeiiq>lary embodiment(s) may 
be in^leiiKented as a c(unbined structure or component These and other variations, modifications, additions, 
30 aikd improvements may fall within the scope of die invention as defined in the claims that follow. 



tSXJOCSD: <WO__01 1 14C2A^I^ 



wo 01/11452 PCTAJS00/2O93I 

-22- 

WHATIS CLAIMED: 

1 . A session credential for use in a security architecture controlling access to one or more 
information resources, Ae session credential conq>rising: 

a principal identifier uniquely identiiying a principal; and 

an encoding of authorization accorded by tiie security architecture after prior authentication of a login 
5 credential corresponding to the principal, 

the principal identifier and authorization encoding being oyptogiaphically secured and allowing the 
security architecture to evaluate sufficiency of the authorization for access to the one or 
more infonnation resources without re-authentication of the login credentials. 

2. A session credential as in claim 1, 

10 wherein the cryptograi^c securing inchides encryption of at least the principal identifier and 

authorization encoding using a private key associated widi the security architectitre. 

3. A session credential as in claim 1, further comprising: 
an encrypted portion and an unencrypted portion; 

the unencrypted portion allowing contents of the session credential, including the principal identifier 
1 5 and authorization encoding, to be read without possession of a key; 

the encrypted portion being encrypted with a private key associated with the security architecture and 

allowing authenticity of the unencrypted portion to be confirmed using a public key 

corresponding to the private key, 

4. A session credential as in claim 3. 

20 wherein the encrypted portion is supplied external to the security architecture as a session token that 

uniquely identifies a corresponding persistent session maintained by the security 
architecture. 

5. A session credential as in claim 4, 

wherein the session token is encoded as a cookie supplied to a browser; and 
25 wherein die cookie is included with access requests made by die browser targetirig the one or more 

infonnation resources. 

6. A session credential as in claim 3, 

wherein the cryptographic securing is by a private key possessed substantially only by an 
authentication component of the security architecture; and 
30 wherein authenticity of the cryptographically secured principal identifier and authorization encoding 

is verifiable by components other than the authentication component using a pubhc key 
corresponding to the private key. 
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7. A session credential as in claiin 1, 

wherein the cryptographic securing includes a digital signature encompassing at least the princq^al 
identifier and authorization encoding and diereby allows authenticity of the princ^l 
identifier and authorization encoding to be confirmed using a public key. 

5 8. A session credential as in claim 1-, further con^rising: 

an expiration encoding. 

9. A session credential as in claim 1, further coQ^}risiiig: 
a session identifier. 

1 0. A session credential as in claim 1, further con^rising: 
10 a group identifier. 

1 1. A session credential as in claim 1, further comprising: 
one or more additional elements selected from 

an e;q}irBtian encoding; 
a session identifier, and 
15 a gioiq) identiHer, 

the one or more additional elements also cryptographically secured. 

12. A session token for transfer between a client entity operating on behalf of a principal and a 
security architecture controlling access to an information resource^ die session token comprising: 

a principal identifier uniquely identifying the principal; and 
20 an indication of authorization level accorded by the security architecture after prior authentication of 

a login credential corresponding to tiie principal 

the principal identifier and authorization level indication being ciyptog;raphically secured and 

allowing the security architecture to evaluate sufficiency of the authorization for access to 
the infoimation resource witiiout re-audientication of the login credentials. 

25 13. A session token as in claim 12, encoded as a cookie stored at a browser. 



14. A session token as in claim 1 2, placed at a browser in response to a set cookie directive by the 
security architecture. 

15. A session token as in claim 12, encoded for transfer to the client entity. 

1 6. A session token as in claim 12, encoded in a communication medium as information in transit 
30 between the client entity and the security architecmre. 
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17. A session token as in claim 12, 

wherein the client entity includes.a browser; and 

wherein the session token is embodied as a cookie supplied to the browser by the security architecture 
and included with an access request made by the browser targeting the tnfomnation resource. 



5 1 8. A method of providing authorization verification in a security architecture controlling access to 

one or more information resources, the method comprising: 

obtaining a login credential and authenticating a principal thereby; 

issuing a cryptographically secured session credential encoding at least an identifier for the principal 
and a fust authorization accorded based on the authenticating; and 
10 for plural requests for accesses to the one or more of the information resources, selectively allowing 

access based on sufficiency of the first authorization encoded by the cryptogr^hically 
secured session credential for access to the one or more of the information resources, 
wherein the selective allowing is performed witiiout additional login credential 
authenticating. 



IS 19. A method as in claim 18« further comprising: 

digitally signing the session credential prior to issuance thereof; and 

prior to the selective allowing, verifying authenticity of the principal identifier and first authorization 
encoding using a public key. 



20. A method as in claim 18, further comprising: 
20 encrypting at least the identifier for the principal and the first authorization using a private key, 

the issued cryptographically secured session credential including at least the identifier for the 

principal and.the first authorization in both encrypted and free text form;- and 
prior to the selective allowing, verifying authenticity of the principal identifier ami first authorization 

encoding using a public key corresponding to the private key. 



25 21. A method as in claim 20, further conQ>rtsing: 

supplying.thc encrypted form of at least the identifier for the principal and the first authorization to a 

client entity external .to the security architecture as a session token; 
the client entity presenting the session token with subsequent access requests so that the security 

architecture may perform the selective allowing of the subsequent access requests without 
30 additional login credential authenticating. 



22. An^ethodas inclaim21, 

wherein the client entity mcludes a browser, and 

wherein the session token is encoded as a cookie. 
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23. A mc&od as in claim 1 8, further comprising: 

on an access request for which die first authorization encoded by the ciyptographically secured 
session credential is insufficient, 

obtaining a second login credential and authenticating the principal ttereby: 
5 issuing a second cryptographically secured session credential encoding a second 

authorization accorded based on the authenticating by the second login aedential; 
and 

selectively allowing the access request based on sufficiency of Ac second authorization 
encoded by the second cryptographically secured session credential. 

10 24. A method as in claim 18» 

wherein die cryptogr^hically secured session credential also encodes an expiration; 
the method further comprising: 

prior to the ejqpiration, reauthcnticatii^ the principal by the first login cicdential; 
issuing a third cryptographically secured session credential encoding a third authorization 
1^ accorded based on the authenticating by die first login credential; and 

selectively allowing subsequent access requests based on sufBciency of the third 

authorization encoded by die third cryptographically secured session credential. 

25. A method as in claim 24, 

wherein the first and third authorizations are equivalent. 

20 26. A method as in claim 24, 

whcxcin die first and third authorizatibn are encoded as trust levels that differ in accordance with 

eidierorboth of a changed session enviromnent and changed mappings of credential types to 
trust levels. 

27. A meduxl as in claim 18, 
25 wherein the login credential is selected firom a set of credential types inchxding one or more of a 

usemame password pair, digital certificate, an encrypted credentials based on asymmetric, 
symmetric, public, private, or secret key technology, a one-dmiB password, a biomctric 
credential based on* retinal scan, voice print, or finger print, and a possession based 
credential embodied in a smart card. Enigma card or physical key. 

30 28. A method as in claim 18, embodied as one or more computer program products including 

functionally descrq)tive information for directing a processor to perform the togin credential obtaining and 
principal audienticating, die cryptographically secured session credential issuing; and die selectively allowing 
access based on sufficiency of die first audiorization by the cryptographically secured session credential, the 
one or more computer program products encoded by or transmitted in at least one coiiq)utcr readable medium 
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selected from the set of a disk, tape or other magnetic, optica), or electronic storage medium and a network, 
wireline, wireless or other communications medium. 

29. An information access control facility comprising: 

. an application proxy for receiving an access request targeting one of the information resources, 

extracting a cryptographically secured session token from the access request, and selectively 
proxying &c access request; 
means responsive to the application proxy for evaluating suffkieitcy of an authorization encoded in 
the cryptographically secured session token for access to the targeted information resource. 

30. An access control facility as in claim 29, further comprising: 

credential gathering means responsive to an insufficient zero or more login credentials associated 
with the session, the credential gathering means obtainii^ a login credential of type 
sufQcient if authenticated, to achieve a trust level requirement of the targeted iiiformation; 
and 

authentication means for receiving die obtained login credential, authenticating a principal thereby 
and issuing a session credential corresponding to the session tokea 

3L An access control facility as in claim 29, further comprising: 

means for transferring.the session token between the access control facility and die client entity. 

32. An access control facility as in claim 29, embodied as a computer program product encoded by or 
trananitted in at least one conqniter readable medium selected from the set of a disk, tape or other magnetic, 
optical, or electronic storage medium and a network, wireline, wireless or othor communications medium. 
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(57) Abstract: A security arcfaitecture has been dcYdopcd in which a single sign-on is provided Session credentials, are used to 
maintain continuity of a pmistent session across multiple accesses to one or more information resources, and in some embodii^ts, 
across credential l^el chafiges.. Session credentials are secured, eg., as a cryptogr^cally secured session token,. sucH thai they 
may be inspected by a. wide variety of entities or applications to verify an amhenticated;trust level, yet may- not l)e prepared or 
altered except by a trusted^authenticaiian service. .Some embodiments of the present invention assddaie trust levcl requiiemMits with 
information resources. Autheaolication schemes (c.g.,.thosc.based on passwords, certificates, biometiic tecfamques, smart caf^^ etc.) 
are associated with trust levels, and in some embodiments, with environmental parameters. For example, in one configuration, a^Ipgin 
service (120) obtains login. oedchlials for an crtity. (e.g., 170).«mimensuiate with the tnist levd recpureroeDt(s)'of an inforination 
resource or infonnationiesources(e.g., 191.192, 193) to be accessed and with enviroiunentparametm that a£^ 
given crcdemlal type. Once login credentials (e.g.. 410) have bcei obtained for an entity ^ 

level session credentials (e.g., 420) are issued and access is granted to information resources for whidi the trust level i5;SufiBctem. 
Advantageously, by using the session credentials access is granted without the need for liirther login oedcntiais and authexttication. 
In some configurations, session credentials evidencing an insufficient tnisi level may be remedied by a session coniimiity preserving 
upgrade of login credential. 
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